Rust 对可靠性的方法不仅仅是避免错误；它是一种 有意识设计的哲学。它将每一个潜在的失败划分为两个领域： 可恢复的 和 不可恢复的 错误。这确保了系统具有韧性、可预测性，并能防止无声的数据损坏。
1. 失败的分类
一个 可恢复错误 （例如文件缺失）是程序可以重试或通知用户的预期障碍。一个 不可恢复错误 （例如缓冲区溢出）代表逻辑上的崩溃，最安全的操作是立即停止——即 快速失败 原则。
2. 基于契约的开发
可靠性通过清晰的边界实现。如果函数的前提条件已满足但外部因素导致失败，则返回一个 Result。如果内部逻辑违反了核心不变量，Rust 将强制中止以防止对系统状态造成进一步损害。
main.py
TERMINALbash — 80x24
> Ready. Click "Run" to execute.
>
QUESTION 1
Which of the following best describes a 'recoverable error' in Rust?
A total breakdown of logic where the program must halt.
An expected situation, such as a missing file, that the program can handle.
A memory leak that is automatically fixed by the compiler.
An error that only occurs in debug mode.
✅ Correct!
Correct! Recoverable errors are anticipated events where the code can take corrective action.❌ Incorrect
Think of errors like a 'File Not Found'—the program doesn't need to crash; it can just ask the user for a different file.QUESTION 2
What is the primary purpose of an 'unrecoverable error' (panic)?
To notify the user that their password was incorrect.
To stop execution immediately when a bug or contract violation is detected.
To provide a way for the program to retry a network request.
To optimize the code for better performance.
✅ Correct!
Exactly. Rust uses panics to 'Fail Fast' and prevent corrupted states from causing further harm.❌ Incorrect
Panics are for bugs and impossible states, not for routine user input issues.QUESTION 3
Why does Rust prefer explicit error handling over exceptions?
To make the code harder to read for security.
To prevent 'silent failures' that lead to corrupted states or vulnerabilities.
Because Rust does not have a stack to bubble up errors.
To allow the program to ignore errors completely.
✅ Correct!
Rust forces you to acknowledge potential failure points at design time, ensuring state integrity.❌ Incorrect
Exceptions often bubble up invisibly; Rust makes the possibility of failure a part of the function's type signature.QUESTION 4
If a function receives input that violates its core invariants (a bug), it should:
Return a Result::Err.
Panic to signal a logic error.
Ignore the input and return a default value.
Print a warning and continue.
✅ Correct!
Correct. If the program enters a state that should be impossible, halting is the safest path.❌ Incorrect
Return a Result for expected failures. If the logic itself is broken, that is a panic-worthy event.QUESTION 5
Which Rust type is used to represent a recoverable failure?
Option<T>
Result<T, E>
panic!
Box<dyn Error>
✅ Correct!
The Result enum explicitly encodes either success (Ok) or a handled failure (Err).❌ Incorrect
The panic! macro is for unrecoverable failures; Result is the container for recoverable ones.Case Study: The Resilient Web Server
Applying error philosophy to system design
You are designing a high-traffic web server. You must decide how to handle two distinct scenarios: 1) A user providing an invalid API key, and 2) The server detecting that its internal routing table has been corrupted by a memory-unsafe operation in a linked C-library.
Q
1. How should the 'Invalid API Key' scenario be handled and why?
Solution:
This should be a recoverable error returned via a
This should be a recoverable error returned via a
Result. It is an expected part of operation; the server should return a 401 status code and continue serving other requests.Q
2. How should the 'Corrupted Routing Table' scenario be handled and why?
Solution:
This must be an unrecoverable error triggering a
This must be an unrecoverable error triggering a
panic!. Since the internal state is corrupt, continuing to process transactions could lead to severe security leaks or data loss. Failing fast is the safest choice.